作者：康子晉｜AWS 解決方案專家，守備範圍橫跨架構設計、維運排錯、成本優化與雲端遷移。
本系列聊一個我最近很有感的主題：怎麼讓 AI 成為團隊裡可靠的一員。

上篇回顧

上一篇我們治好了 AI 的第一個毛病——唬爛：給它查證工具（MCP）+ 一條「先查後答」的紀律。

這篇來處理那個更根本、也更煩人的毛病：失憶。

失憶的本質：每次對話都從零開始

你有沒有發現，每開一個新對話，AI 就像第一天上班的新人：

• 不知道你是誰、做什麼工作
• 不知道你們團隊的規矩、慣用的工具
• 不知道你偏好怎樣的回答方式

於是你每次都要重講一遍：「我是做 AWS 維運的，回答請用繁體中文，不要長篇大論，技術聲明要先查證……」講到你自己都煩。

這是因為 LLM 本身沒有跨對話的長期記憶。每次對話它能看到的，只有「這一次你餵給它的 context」。新對話 = 空白的 context = 一個全新的失憶新人。

那怎麼辦？答案很直覺：幫他寫一份員工手冊，而且規定他每天上班第一件事就是先讀過一遍。

第一招：Steering——永遠在線的常駐規範

在 Kiro 裡，這份「員工手冊」叫 Steering。它就是一份放在專案裡的 markdown 檔（.kiro/steering/），最大的特色是：預設每次對話都會自動載入（always 模式），不用你提醒，AI 開工前一定先讀。

補充：Steering 有幾種載入時機

「我是誰、團隊規矩」用 always 永遠在線；各帳號明細這種「講到才需要」的，我設成 auto——靠 description 的關鍵字自動觸發，要用的時候才載入，平常不佔 context。這就是控制「常駐成本」的關鍵手段。

這一招解決的，正是「每次都要重新自我介紹」的痛。

關鍵心法：別把手冊塞成一坨

很多人寫 Steering 會犯一個錯：把所有東西全塞進一個檔案——自我介紹、規矩、技術棧、專案細節，全部混在一起。結果又臭又長，AI 讀起來抓不到重點，你自己也難維護。

我的做法是按「角色」拆檔，每個檔只回答一個問題：

範例一：靈魂.md——告訴它「我是誰」

# 靈魂

## 偏好與雷區
- 回答用繁體中文，簡潔直接，不要長篇大論
- 重視 context 效率，討厭冗餘的客套話
- 給技術方案時要列「限制」，不要只報喜

## 口吻
- 輕鬆口語、直來直往，不要官腔

這就是一份「員工性格說明書」。AI 每次上工先讀過，自然就用你喜歡的方式回話。

範例二：guardrails.md——告訴它「做事的紀律與紅線」

# 行為準則

## 安全紅線（絕對不能違反）
- 對 production 環境的任何寫入操作，必須先取得我確認，無例外
- 不確定的技術限制，先查官方文件，不要憑記憶亂講
- 不替我做決定，列出選項讓我選

## 回覆風格
- 用表格呈現比較結果與資源狀態
- 技術方案要標「限制」和「風險等級」

這份就是「員工守則」。最有價值的是那條 production 紅線——它讓 AI 在動危險操作前一定先停下來問你，而不是自作主張。

範例三：account-*.md——告訴它「我管哪些帳號、裡面有什麼」

這層是我覺得最實用的。維運常常要面對好幾個 AWS 帳號，每個帳號的用途、ID、跑了哪些服務都不一樣。我幫每個帳號各寫一個檔（如 account-techdept.md），並設成 auto 模式：

---
inclusion: auto
name: account-techdept
description: 技術部測試帳號資源清單。當使用者提到 技術部、techdept、測試帳號 時自動載入。
---

# 技術部測試帳號

- 帳號 ID：1234-5678-9012
- 用途：技術部內部測試、PoC、混沌工程演練
- 區域：ap-northeast-1（東京）

## 主要資源
- EKS 叢集 ×1（測試 K8s 工作負載）
- RDS MySQL ×1（測試資料庫）
- Lambda ×數個（自動化小工具）
- 多個 NAT Gateway / EIP（注意：閒置也會計費）

注意最上面那段 frontmatter：auto 模式需要 name 和 description 兩個欄位，其中 description 就是「自動載入的觸發條件」。當我講到「技術部」，Kiro 會比對這段描述、判斷相關後自動把這個檔拉進對話——平常它不佔 context，要用的時候才出現。（這個機制跟 Kiro 的 Skills 是同一套邏輯。）

有手冊 vs 沒手冊：差在哪

講再多不如看實際差異。我只丟一句話：「幫我檢查技術部帳號的費用」。

沒有 Steering（失憶新人）

請問「技術部帳號」是哪一個帳號呢？方便提供 account ID 嗎？
另外你想查哪個區域、哪些服務的費用？
（結果：反問你一堆，因為它根本不知道「技術部帳號」是什麼）

有 Steering（讀過手冊的同事）

收到，技術部測試帳號（1234-5678-9012，東京區）。我去拉它的費用明細。
初步看：大頭是那幾個閒置的 NAT Gateway 和 EIP——這帳號是測試用，但這些就算沒在跑也照算錢，建議優先檢視。
（結果：它知道「技術部帳號」=哪個 ID、裡面有什麼，直接開工，還主動點出最可能浪費錢的地方）

這個落差，就是「員工手冊」的價值。你用一個只有「自己人才懂」的簡稱（技術部帳號），它就能對上正確的帳號與脈絡——因為這些事它早就記在手冊裡了。你前期花時間把脈絡寫清楚，後面省下的是「每次都要重新交代」的無數時間。

為什麼「分層」這麼重要

兩個原因：

1. Context 效率：always 載入的東西會佔用每次對話的 context（也就是會吃 token）。分層之後，你能清楚控制「什麼東西值得永遠在線」，而不是塞一堆雜訊進去拖慢、增加成本。
2. 好維護：規矩改規矩、偏好改偏好，各自獨立。改一個地方不會牽動其他。

這也帶出一條我自己的紀律：Steering 是常駐成本，要精挑細選。 只放「每次對話都用得到的核心脈絡」，一次性的專案細節不要塞進來。

帶走的三個重點

1. AI 失憶是天性，不是 bug。 它沒有跨對話記憶，每次都是新人。
2. 用一份「常駐手冊」（Steering）治標準失憶。 規定它每次上工先讀，省下重複自我介紹。
3. 手冊要分層、要節制。 按角色拆檔（我是誰／規矩／技術棧），只放值得永遠在線的東西。

不過你可能已經發現一個問題：員工手冊是靜態的，寫好就放著。但工作中每天會發生新的事——今天解決了什麼 bug、做了什麼決定——這些「動態的記憶」怎麼讓 AI 也記住？

下一篇，來聊我怎麼幫 AI 建一本會自己長大的「工作日誌」，還會自動整理、不會爆炸。

✍️ 關於作者

康子晉
做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖和客戶為伍。
這個系列記錄我怎麼把 AI 從「會聊天」調教成「能幹活的同事」。

如果這篇對你有幫助，歡迎追蹤這個系列，或來這裡找我聊聊：
🔗 LinkedIn：LinkedIn

第一篇: https://ithelp.ithome.com.tw/articles/10400259